1. Field of the Invention
The present invention relates to diagnostic tools for analyzing software. More particularly, the invention is directed to the dynamic instrumentation of running software in order to gather runtime data as the software executes. Still more particularly, the invention concerns a technique for implementing a portable dynamic instrumentation tool that accommodates variations in execution environment that arise from differences in compiler versions, compile options, hardware platform particulars and other parameters.
2. Description of the Prior Art
By way of background, in order to analyze the operation of a complex system such as a large software program, it is important to be able to gather operational information while the system is running, without halting execution, modifying the system, and then restarting it. One approach is to dynamically add instrumentation code to the running system when data is needed, so that there is no performance penalty. This is in contrast to statically instrumenting the system when it is created, which offers no flexibility. Operating systems are examples of complex systems that may require diagnosis at run time. As shown in FIG. 1A, it is often desirable to probe some kernel function to determine information about its operation, such as how often or why the function is being called. The kernel memory location where the function is to be probed is referred to as the probe point. As shown in FIG. 1B, dynamic instrumentation involves adding a software interrupt at the probe point in the running system and providing a probe handler that is executed when the interrupt throws an exception. The probe handler executes instrumentation code (instrumentation function) that obtains the required information and provides it to the probe user, then returns control to the running system. Examples of such conventional dynamic instrumentation software include the Linux® System Tap framework. This framework provides a Linux® tool that allows application developers and system administrators to write probe scripts that will be automatically parsed, elaborated upon, translated, compiled and loaded as a kernel module to generate probe data from a running kernel.
One problem with conventional instrumentation solutions is that the probe handler needs the same execution environment as that of the function being interrupted, including access to local variables and arguments. Unfortunately, the location of local variables and arguments is not fixed, and depends on various parameters such as the compiler version used to compile the operating system, and the compile options and hardware platform type specified during compilation. For this reason, local variables and arguments can not be easily accessed in the probe handler without consulting additional debug information. It is not desirable to access debug information from a probe handler insofar as this information is generally not readily available to the operating system. For example, the kernel debug information is typically maintained in a file system that is readily accessible in user space but not from kernel context. Due to this problem, it is not easy to write dynamic instrumentation code in a portable form. The only known alternative is to write the probe handler code for a specific version of the compiler, compile options and platform being utilized. It will be appreciated that this method is not desirable insofar as it is not practical or economical to write such code.
Accordingly, it would be desirable to provide a technique whereby a probe handler could reference the same execution environment as that of the function being interrupted without consulting debug information from the handler. The technique should be powerful enough so that it can be extended to dynamically add new functionality or fix a problem in an existing system without taking the system down.